1. Field of the Disclosure
This disclosure relates generally to networks. More particularly, the disclosure relates to Ethernet operations, administration and maintenance (Ethernet OAM or sometimes EOAM). Ethernet OAM protocols handle installing, monitoring, and troubleshooting Ethernet networks.
Ethernet OAM as currently defined in IEEE standard 802.1ag “Connectivity Fault Management”, incorporated herein by reference, defines a connectivity fault management protocols for use in Ethernet networks. The functions of that protocol include: continuity check, link trace, and loopback protocols. An analogous standard with performance monitoring metrics and messages is defined in ITU-T Y.1731—“Requirements for OAM in Ethernet Networks”, also herein incorporated by reference. Additional potentially relevant work is ongoing in ITU-T Study Group 13 (often “SG 13”).
While the IEEE 802.1ag standard and the ITU-T Y.1731 address similar concepts, they frequently use different terms. However, a person of ordinary skill in the art is able to understand a concept expressed using the terms unique to either standard. For simplicity, the application that follows uses the terminology from the IEEE 802.1 ag standard. The largely corresponding terms found in ITU-T Y.1731 are set forth below.
IEEE 802.1agITU Y.1731MD (Maintenance Domain)MEL (Maintenance Entity Level)MA (Maintenance Association)MEG (Maintenance Entity Group)MEP (Maintenance End Point)MEP (Maintenance End Point)MIP (Maintenance Intermediate MIP (Maintenance Intermediate Point)Point)PortExternal Interface (UNI, NNI)
Note, the application and the expressions of the scope of inventive concepts that follow use the term EVC (Ethernet Virtual Circuit) which is not defined per se in the IEEE standard. EVC is a well-understood term to those of skill in the art. The term EVC includes both point to point and multipoint Ethernet network configurations.
Thus, while expressions of the scope of inventive concepts from this application may use terms from one particular standard, unless explicitly noted to the contrary, these expressions of the scope of inventive concepts are intended to apply to the IEEE 802.1 ag standard and the ITU-T Y.1731 standard, and their successors, including any new or proprietary standards that partially implement these standards. Likewise, the expressions of the scope of inventive concepts should be interpreted to apply to any new standard that provides guidance for the relevant concepts currently found in the IEEE 802.1 ag standard and the ITU-T Y.1731 standard, even if that new standard (like the ITU-T Y.1731 standard) does not use the terminology used in the IEEE 802.1 ag standard.
2. Background
Connectivity Fault Management (CFM).
Connectivity Fault Management (CFM), as used in the IEEE 802.1ag and standards, creates a complex hierarchy of logical objects for path management that must be maintained across an entire network for proper operation and communication. The ITU-T Y.1731 standard uses Ethernet OAM for an analogous set of concepts. In order to simplify the discussion within this document and the expressions of the scope of inventive concepts, the term CFM is intended to cover both the relevant IEEE and ITU concepts. As shown in FIG. 1, the basic CFM objects include Maintenance Point (MP) 104, Maintenance Association (MA) 108, and Maintenance Domain (MD) 112. Note that the Maintenance Point 104 is associated with a logical port 116. As noted above, a logical port may be known as a UNI or NNI (User Network Interface or Network Network Interface). The Maintenance Association 108 is associated with the EVC (Ethernet Virtual Circuit) 120. A logical port 116 will be associated with a physical port 124. An EVC may be associated with one or more VLANs 128 The various concepts are introduced in more detail below.
Maintenance Domain (MD).
A MD 112 is identified by a level (between 0 and 7) that a set of CFM systems will communicate on. The level is designed to provide a hierarchy of network domains with Service Providers using the lowest levels and terminal customers using the highest levels. According to standards, CFM traffic at a specific level may not cross into a higher level, meaning Customer networks should never see Service Provider CFM traffic. A simplified representation of Maintenance Domains is shown in FIG. 2. A series of five networks are shown in FIG. 2. Moving from left to right there is customer network 204, provider network 208, operator network 212, provider network 216, and customer network 220. The operator MD level 280 runs between interface 258 at the edge of provider network 208 to interface 262 at the edge of provider network 216. The provider MD level runs from interface 254 at the edge of customer network 204 to interface 266 at the edge of customer network 220. The customer MD level extends all the way across the networks to include both the customer network 204 and the customer network 220.
Maintenance Point (MP).
The MP 104 identifies a logical port 116 that the CFM system will monitor. One of skill in the art will recognize that a single physical port 124 could serve as more than one logical port 116. The MP 104 must have a globally unique tag and depending on the MPs function (end-point, intermediate-point, or half-function) must also be pointed in the proper direction of the CFM network. Maintenance End Points (MEPs) and Maintenance Intermediate Points (MIPs) are both examples of MPs. The concepts discussed below primarily focuses on the configuration and maintenance of MEPs.
One of skill in the art will recognize that an instance of OAM may support multiple MEPs. For example, an individual device that supports multiple instances of an Ethernet Virtual Circuit (EVC) or Component EVC (CEVC) may also have a separate MEP for each EVC. Likewise, a single EVC that supports more than one MD level, or more than one MA may also have more than one MEP.
Maintenance Association (MA).
The MA 108 identifies a collection of MEPs that communicate via CFM. These MEPs may operate on a specific EVC 120. A given EVC may have zero, one, or more VLANs 128 (Virtual Local Area Network) operating on the EVC. The MA also provides a name for a set of MEPs that must be configured the same on all CFM nodes communicating in this MA. A simplified representation of Maintenance Association is shown in FIG. 3. In FIG. 3, a provider network 300 is connected to customer edge 354, customer edge 358, and customer edge 362. A first MA is associated with VLAN1 304 and a second MA is associated with VLAN2 308.
Thus, the Maintenance Association defines a set of MEPs all of which are configured with the same Maintenance Association Identifier (MAID) and MD Level (0 to 7). Each MEP within a Maintenance Association has a complete list of all MEP IDs within that Maintenance Association.
In addition to the basic objectives that allow a CFM enabled device to communicate with others, each MEP must also be configured with knowledge of all other MEPs that the CFM enabled device expects to exchange OAM traffic with. These objects are sometimes referred to as remote-MEPs (R-MEPs).
Continuity Check Protocol.
Continuity Check Message (CC message or CCM) is a way to detect connectivity failures. When enabled under Ethernet Continuity Check Function (ETH-CC), the use of CC messages is part of a proactive monitoring for faults including the loss of continuity between any pair of MEPs.
A CC message is a multicast message confined to a MD. The messages are unidirectional and do not solicit a response. Each MEP transmits a periodic multicast CC message towards the other MEPs. The CC message is sometimes referred to as a “heart beat” message.
External Interfaces (EIs).
Ethernet OAM standards often identify three types of Deployment Roles—Customers, Operators, and Service Providers. Logical port interfaces between administrative entities are often referred to as External Interfaces (EIs). Two common types of EIs are User-to-Network Interfaces (UNIs) and Network-to-Network Interfaces (NNIs).
FIG. 4 has a simplified drawing of a series of External Interfaces between the operator domain 404 and the provider domain 434 and again between the provider domain 434 and the customer domain 464. MEPs are often deployed at interfaces between administrative entities so that one entity can monitor the service it provides to another entity ‘end-to-end’, while the higher entity can monitor the service that it is buying. For example, between an operator edge 408 and a provider edge 438 or between a provider edge 438 and a customer edge 468.
Creating and maintaining the object hierarchy manually for a few devices may not be difficult, however, this process does not scale well—as manual configuration is complex and error-prone. Thus, prior art solutions would benefit from a system that can automatically detect CFM networks and configure the objects required to become a part of the CFM infrastructure.
FIG. 5 provides a state diagram describes a prior art state machine used to create and join a CFM network and shows the complexity inherent in the distributed nature of the network configuration. Step 504 is start. Step 508 is create MD (may be done by end user).
Step 512 is create MA (may be done by end user). Step 512 is create MP (may be done by end user). Step 520 is the Send/Receive Continuity Check messages. The receipt of a new Continuity Check message triggers Step 524. Step 524 is to Create RMEP also known as remote-MEPs or R-MEPs (may be done by end user). If the newly created RMEP is tested at node 528 and is a duplicate of a known RMEP, then there is an error 532 and remedial action may be required.
Creating and maintaining the object hierarchy manually for a few devices may not be difficult, however, this process does not scale well—as manual configuration is complex and error-prone. Thus, prior art solutions would benefit from a system that can automatically detect CFM networks and configure the objects required to become a part of the CFM infrastructure.